home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / fido218.nqs / fido218.nws
Encoding:
Text File  |  1985-07-12  |  10.8 KB  |  331 lines
  1. FIDONEWS     --           17 Jun 85  00:00:20           Page 1
  2.  
  3.         Volume 2, Number 18                             17 June 1985
  4.         +----------------------------------------------------------+
  5.         |                                             _            |
  6.         |                                            /  \          |
  7.         |    - FidoNews -                           /|oo \         |
  8.         |                                          (_|  /_)        |
  9.         |  Fido and FidoNet                         _`@/_ \    _   |
  10.         |    Users  Group                          |     | \   \\  |
  11.         |     Newsletter                           | (*) |  \   )) |
  12.         |                             ______       |__U__| /  \//  |
  13.         |                            / FIDO \       _//|| _\   /   |
  14.         |                           (________)     (_/(_|(____/    |
  15.         |                                                (jm)      |
  16.         +----------------------------------------------------------+
  17.  
  18.         Publisher:              Fido 107/375
  19.         Chief Procrastinator:   Thom Henderson
  20.  
  21.         Fidonews is published weekly by SEAboard, Fido 107/375.  You 
  22.         are  encouraged  to  submit  articles  for  publication   in 
  23.         Fidonews.  Article submission standards are contained in the 
  24.         file FIDONEWS.DOC, available from Fido 107/375.  
  25.  
  26.         Disclaimer or don't-blame-us:
  27.  
  28.         The  contents  of  the  articles  contained here are not our 
  29.         responsibility,  nor do  we  necessarily  agree  with  them; 
  30.         everything here is subject to debate.  We publish EVERYTHING 
  31.         received.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.                         In Defense of Copy Protection
  38.  
  39.         No, I haven't lost my marbles.  And no, I don't like copy 
  40.         protection either.  But there IS more than one side to this 
  41.         issue, and I'd just like to point out a few facts for the 
  42.         other side.
  43.  
  44.         The major problem in this industry today is software piracy.  
  45.         It's been estimated that over half the copies of 1-2-3 in 
  46.         use by major corporations are pirate copies.  Wordstar does 
  47.         even worse than that.  One of my sources tells me of a major 
  48.         international corporation where almost every PC is equipped 
  49.         with a large assortment of pirated software, and the people 
  50.         using it see nothing wrong.
  51.  
  52.         I've lost count of how many times I've heard people complain 
  53.         that the software houses should "get rid of expensive copy 
  54.         protection and just price the stuff reasonably."  I'm told 
  55.         that Lotus charges far too much for 1-2-3, and that if they 
  56.         only asked (figure varies, generally under a hundred bucks) 
  57.         then nobody would pirate it and they'd make more money.  
  58.  
  59.         Bull chips.  They could sell it for ten bucks a pop, and 
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67. FIDONEWS     --           17 Jun 85  00:00:22           Page 2
  68.  
  69.         people would STILL pirate it.  As for the price being 
  70.         unreasonable, I have news for you.  The retail price of 
  71.         1-2-3 would just about get you my services for ONE DAY, so 
  72.         think for a minute how much 1-2-3 would cost if you tried to 
  73.         get someone to write it for you.
  74.  
  75.         The upshot is that when a company does an honest piece of 
  76.         work and produces a quality piece of software, they deserve 
  77.         to make some bucks on it.
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133. FIDONEWS     --           17 Jun 85  00:00:22           Page 3
  134.  
  135.         ============================================================
  136.                                   NEWS
  137.         ============================================================
  138.         In view of the expansion of Fido, I would like to propose an 
  139.         idea for reduced-cost mail, involving low overhead on the 
  140.         part of each local board, and a LARGE overhead on the part 
  141.         of the network manager.  
  142.  
  143.         Fido COULD send mail from local dialing area to local 
  144.         dialing area, but to do this would involve creating a graph 
  145.         containing all Fidos, each graph containing COMPLETE routing 
  146.         instructions for point-to-point transfer.  At each receiving 
  147.         station, (pardon my LISP) take CAR(ROUTE-LIST) as the next 
  148.         node to transmit to, and send CDR(ROUTE-LIST) as the New 
  149.         ROUTE-LIST.  Upon arrival at the desired point, CAR(ROUTE-
  150.         LIST)=NIL, and the message has arrived at its final 
  151.         destination.  The file sent could easily be small relative 
  152.         to ROUTE-LIST, and each Fido would have to store (#NODES)^2 
  153.         maximum ATOMS - this is a HUGE amount of disk overhead.  
  154.  
  155.         The idea I would like to suggest would be that each FIDO 
  156.         store a route map for its LOCAL hub only, with designated 
  157.         Fido GATEWAYS to the next hub in the direction of travel.  
  158.         Each GATEWAY would have LOCAL numbers leading into a new 
  159.         hub, would check the final-destination address, and pass it 
  160.         to the next hub.  The incoming gateway would then route to 
  161.         an appropriate gateway in its hub, or to its final 
  162.         destination if in the current hub.  
  163.  
  164.         The biggest problem in this is the construction of the map - 
  165.         and what to do in the event of a GATEWAY FAILURE (i.e. the 
  166.         gateway is down or otherwise unable to pass messages).  
  167.         Adaptive routing would be nice, except that this involves a 
  168.         large communications overhead (each active node must 
  169.         periodically pass the list of LOCAL Fidos that it can 
  170.         actually contact to each GATEWAY in its hub.)  My guess is 
  171.         that this would entail an additional 15-20 minutes per day 
  172.         (or mail period) in receiving and transmitting local connect 
  173.         information.  If adaptive routing is not made automatic, one 
  174.         node would have to determine the map of local nodes and 
  175.         gateways, and go from there.  Inter-hub linkages should be 
  176.         made redundant (i.e. if hub 1 wants to talk to hub 2, there 
  177.         should be more than one gateway to hub 2, if at all 
  178.         possible.) 
  179.  
  180.         The message traffic bottleneck would come at the GATEWAYS - 
  181.         it would be essential that (1) the gateway have sufficient 
  182.         hard disk storage to hold all incoming or outgoing mail for 
  183.         the HUB!!! and (2) the gateway have the capability of 
  184.         reporting to the net the failure of another gateway, so that 
  185.         alternative routing can be generated.  The mathematics 
  186.         involved in this part of the problem would be (1) topology 
  187.         and (2) graph theory.  Andrew Tannenbaum's "Computer 
  188.         Networks" (Addison-Wesley, 1981) discusses these topics in 
  189.         relation to mainframe point-to-point networks (the examples 
  190.         are ARPANet and IBM's SNA), and discuss the possible 
  191.         solutions.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199. FIDONEWS     --           17 Jun 85  00:00:25           Page 4
  200.  
  201.  
  202.         I currently have a program which is used to solve this type 
  203.         of problem in a generic sense - it is a modification of DR's 
  204.         NETWORK2.PLI program.  In order to use this program, it is 
  205.         necessary to construct an exhaustive list of the local 
  206.         dialing area overlap relative to FIDO nodes.  This program 
  207.         as presently written is memory bound - I do not think that 
  208.         the mapping for a 1000 node system could be stored in less 
  209.         than 384K on a PC under PC-DOS 2.1 (we run the program on 
  210.         the CompuPro here in house to solve LAN gateway problems.) 
  211.  
  212.         Under Fido version 10i, the point-to-point could only be 
  213.         handled within a local hub - there are two main reasons that 
  214.         it would be difficult to use for other purposes: 
  215.  
  216.         (1)  There is no provision in the FidoMail to place more 
  217.         than a total of two destinations for a file - the first is a 
  218.         transmit-to address for an incoming gateway, the second 
  219.         being the final distribution address.  This would make it 
  220.         possible to make a two-jump transfer - transmit to an 
  221.         incoming during National Mail, and then redistribute during 
  222.         a local mail period.  This would be practical for messages 
  223.         between, say, New Haven and Bridgeport, with an incoming 
  224.         station in Milford.  
  225.  
  226.         (2)  The amount of time it would take to make a long 
  227.         distance trip would be prohibitive.  Suppose that using 
  228.         local-to-local jumps, you could have a message make three 
  229.         jumps per day - about 50-70 miles.  It would take about 40 
  230.         days to get to a destination in California!!!  Also, 
  231.         discontinuities would exist between many locations - those 
  232.         locations would be unreachable under the FREEMAIL concept.  
  233.         In the event of a gateway failure, either a new FREEMAIL 
  234.         route would be needed (adaptive routing), or the mail would 
  235.         be further delayed - possibly forever if the gateway remains 
  236.         down.  
  237.  
  238.  
  239.         Any suggestions or comments should be sent to:
  240.  
  241.         Ed Rauh
  242.  
  243.         FIDO 215 (BCP Technology) 
  244.         (203) 777-7763 
  245.         (300/1200 baud, 8-1-N or 7-1-E)
  246.  
  247.         Bulldog Computer
  248.         1334 Chapel Street
  249.         New Haven, CT  06511
  250.  
  251.         Incidentally, we have several unique ports of Fido, one to 
  252.         our Turbo PC (runs at 7 MHz) under a modified CPC-DOS 3.2, 
  253.         and another under MS-PRO (MS-DOS 2.1 for the CompuPro from 
  254.         Computer House.) 
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265. FIDONEWS     --           17 Jun 85  00:00:27           Page 5
  266.  
  267.         ============================================================
  268.                                NOTICES
  269.         ============================================================
  270.         * * * WARNING * * * WARNING * * * WARNING * * * WARNING * * *
  271.  
  272.                                PIRACY WARNING
  273.  
  274.         Several game programs have been making the rounds, billed as 
  275.         public domain versions of Atari games.  This includes (but 
  276.         is not limited to) the following games:
  277.  
  278.             STARGATE
  279.             ROBOTRON
  280.             MOONBUGS
  281.             ZAXXON
  282.  
  283.         If you have any of these games on your board, please remove 
  284.         them as soon as possible.
  285.  
  286.         ------------------------------------------------------------
  287.                          *** Calendar of Events ***
  288.  
  289.         18 Jun 85 RSVP deadline for the Next Occasional MetroNet 
  290.                   Sysop Meeting.
  291.  
  292.         22 Jun 85 The Next Occasional MetroNet Sysop Meeting.
  293.  
  294.         23 Jun 85 Submissions deadline for next issue of Fidonews.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.         If you have any event you want listed in this calendar, 
  303.         please send a note to node 107/375.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.